home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1993 / Internet Info CD-ROM (Walnut Creek) (1993).iso / inet / internet-drafts / draft-ietf-pppext-isdn-02.txt < prev    next >
Text File  |  1993-09-22  |  19KB  |  608 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                        W A Simpson
  8. Internet Draft                                                Daydreamer
  9. expires in six months                                     September 1993
  10.  
  11.  
  12.                              PPP over ISDN
  13.                      draft-ietf-pppext-isdn-02.txt
  14.  
  15.  
  16.  
  17. Status of this Memo
  18.  
  19.    This document is the product of the Point-to-Point Protocol Working
  20.    Group of the Internet Engineering Task Force (IETF).  Comments should
  21.    be submitted to the ietf-ppp@ucdavis.edu mailing list.
  22.  
  23.    Distribution of this memo is unlimited.
  24.  
  25.    This document is an Internet Draft.  Internet Drafts are working
  26.    documents of the Internet Engineering Task Force (IETF), its Areas,
  27.    and its Working Groups.  Note that other groups may also distribute
  28.    working documents as Internet Drafts.
  29.  
  30.    Internet Drafts are draft documents valid for a maximum of six
  31.    months.  Internet Drafts may be updated, replaced, or obsoleted by
  32.    other documents at any time.  It is not appropriate to use Internet
  33.    Drafts as reference material or to cite them other than as a
  34.    ``working draft'' or ``work in progress.''
  35.  
  36.    Please check the 1id-abstracts.txt listing contained in the
  37.    internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net,
  38.    nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the
  39.    current status of any Internet Draft.
  40.  
  41.  
  42.  
  43.  
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Simpson                  expires in six months                  [Page i]
  59. DRAFT                        PPP over ISDN                September 1993
  60.  
  61.  
  62. Abstract
  63.  
  64.    The Point-to-Point Protocol (PPP) [1] provides a standard method for
  65.    transporting multi-protocol datagrams over point-to-point links.
  66.  
  67.    This document describes the use of PPP over Integrated Services
  68.    Digital Network (ISDN) switched circuits.
  69.  
  70.  
  71. Applicability
  72.  
  73.    This specification is intended for those implementations which desire
  74.    to use the PPP encapsulation over ISDN point-to-point links.  PPP is
  75.    not designed for multi-point or multi-access environments.
  76.  
  77.    "It is clear that there is never likely to be a single, monolithic,
  78.    worldwide ISDN." [7] The goal of this document is to describe a few
  79.    common implementations, chosen from the current wide variety of
  80.    alternatives, in an effort to promote interoperability.
  81.  
  82.  
  83.  
  84.  
  85.  
  86.  
  87.  
  88.  
  89.  
  90.  
  91.  
  92.  
  93.  
  94.  
  95.  
  96.  
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113. Simpson                  expires in six months                 [Page ii]
  114. DRAFT                        PPP over ISDN                September 1993
  115.  
  116.  
  117. 1.  Introduction
  118.  
  119.    PPP was designed as a standard method of communicating over point-
  120.    to-point links.  Initial deployment has been over short local lines,
  121.    leased lines, and plain-old-telephone-service (POTS) using modems.
  122.    As new packet services and higher speed lines are introduced, PPP is
  123.    easily deployed in these environments as well.
  124.  
  125.    This specification is primarily concerned with the use of the PPP
  126.    encapsulation over ISDN links.  Since the ISDN B-channel is by
  127.    definition a point-to-point circuit, PPP is well suited to use over
  128.    these links.
  129.  
  130.    The ISDN Primary Rate Interface (PRI) may support many concurrent B-
  131.    channel links.  The PPP LCP and NCP mechanisms are particularly
  132.    useful in this situation in reducing or eliminating hand
  133.    configuration, and facilitating ease of communication between diverse
  134.    implementations.
  135.  
  136.    The ISDN D-channel can also be used for sending PPP packets when
  137.    suitably framed, but is limited in bandwidth and often restricts
  138.    communication links to a local switch.
  139.  
  140.    The terminology of ISDN can be confusing.  Here is a simple graphical
  141.    representation of the points used in subsequent descriptions:
  142.  
  143.                    +-------+     +-------+     +-------+
  144.                R   |       |  S  |       |  T  |       |   U
  145.                +---+  TA   +--+--+  NT2  +--+--+  NT1  +---+
  146.                    |       |     |       |     |       |
  147.                    +-------+     +-------+     +-------+
  148.  
  149.    These elements are frequently combined into a single device.
  150.  
  151.  
  152.  
  153.  
  154.  
  155.  
  156.  
  157.  
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168. Simpson                  expires in six months                  [Page 1]
  169. DRAFT                        PPP over ISDN                September 1993
  170.  
  171.  
  172. 2.  Physical Layer Requirements
  173.  
  174.    PPP treats ISDN channels as bit or octet oriented synchronous links.
  175.    These links MUST be full-duplex, but MAY be either dedicated or
  176.    circuit-switched.
  177.  
  178.    Interface Format
  179.  
  180.       PPP presents an octet interface to the physical layer.  There is
  181.       no provision for sub-octets to be supplied or accepted.
  182.  
  183.       The octet stream is applied primarily at the R or T reference
  184.       points.
  185.  
  186.    Transmission Rate
  187.  
  188.       PPP does not impose any restrictions regarding transmission rate,
  189.       other than that of the particular ISDN channel interface.
  190.  
  191.    Control Signals
  192.  
  193.       PPP does not require the use of control signals.  When available,
  194.       using such signals can allow greater functionality and
  195.       performance.  Implications are discussed in [2].
  196.  
  197.       Control signals MAY be required by some of the framing techniques
  198.       described, and is outside the scope of this specification.
  199.  
  200.    Encoding
  201.  
  202.       The definition of various encodings and scrambling is the
  203.       responsibility of the DTE/DCE equipment in use, and is outside the
  204.       scope of this specification.
  205.  
  206.       While PPP will operate without regard to the underlying
  207.       representation of the bit stream, lack of standards for
  208.       transmission will hinder interoperability as surely as lack of
  209.       data link standards.  The D-channel LAPD interface requires NRZ
  210.       encoding at the T reference point.  Therefore, as a default, it is
  211.       recommended that NRZ be used over the B-channel interface at the T
  212.       reference point.  This will allow frames to be easily exchanged
  213.       between the B and D channels.
  214.  
  215.       When configuration of the encoding is allowed, NRZI is recommended
  216.       as an alternative in order to ensure a minimum ones density where
  217.       required over the clear B-channel, with caveats regarding FCS [2].
  218.  
  219.       Historically, some implementations have used Inverted NRZ (merely
  220.  
  221.  
  222.  
  223. Simpson                  expires in six months                  [Page 2]
  224. DRAFT                        PPP over ISDN                September 1993
  225.  
  226.  
  227.       switching the sense of mark and space), in order to ensure a
  228.       minimum ones density with bit-synchronous HDLC.  The use of
  229.       Inverted NRZ is deprecated.
  230.  
  231.       Automatic Detection
  232.  
  233.          Implementations which desire to interoperate with multiple
  234.          encodings MAY choose to detect those encodings automatically.
  235.          Automatic encoding detection is particularly important for
  236.          Primary Rate Interfaces, to avoid extensive pre-configuration.
  237.          Only simple encodings are currently distinguished.
  238.  
  239.          The only reliable method of detection available is to switch
  240.          modes between the supported encodings.  Transmission of the LCP
  241.          Configure-Request SHOULD be tried twice for each mode before
  242.          switching in rotation.  This ensures that sufficient time is
  243.          available for a response to arrive from the peer.
  244.  
  245.          Max-Configure MUST be set such that the cumulative attempts
  246.          result in no more than 59 seconds of time before disconnect.
  247.          It is preferable that the usual limit of 30 seconds be
  248.          observed.
  249.  
  250.       Prior Configuration
  251.  
  252.          By prior configuration, PPP MAY also be used with other
  253.          encodings.  Because of difficulty distinguishing them, it is
  254.          not recommended that these encodings be automatically detected.
  255.  
  256.          Terminal adapters conforming to V.120 [6] can be used as a
  257.          simple interface to workstations.  Asynchronous HDLC framing
  258.          [2] is accepted at the R reference point.  The terminal adapter
  259.          provides async-sync conversion.  Multiple B-channels can be
  260.          used in parallel.  Unfortunately, V.120 has a framing mode of
  261.          its own for rate adaptation, which is difficult to distinguish
  262.          from Frame Relay, and which can confuse in-band frame
  263.          detection.  V.120 is not interoperable with bit-synchronous
  264.          links, since V.120 does not provide octet-stuffing to bit-
  265.          stuffing conversion.  Therefore, V.120 is deprecated in favor
  266.          of more modern standards, such as "PPP in Frame Relay" [4].
  267.  
  268.          The "Bandwidth On Demand Interoperability Group" has defined a
  269.          proposal called BONDING.  Multiple B-channels can be used in
  270.          parallel.  BONDING has an initialization period of its own,
  271.          which might conflict with the simple detection technique
  272.          described above, and requires extensive individual
  273.          configuration in some current implementations when multiple B-
  274.          channels are involved.  It is recommended that the PPP
  275.  
  276.  
  277.  
  278. Simpson                  expires in six months                  [Page 3]
  279. DRAFT                        PPP over ISDN                September 1993
  280.  
  281.  
  282.          multilink procedure [5] be used instead of BONDING.
  283.  
  284.  
  285. 3.  Framing
  286.  
  287.    For B-channels, in the absence of prior configuration, the
  288.    implementation MUST first use bit-synchronous HDLC [2], as opposed to
  289.    other framings, for initial link establishment.  This assumes that
  290.    circuit-switched communications are generally [host | router] to
  291.    [host | router].  The implementation MAY change to X.25 or Frame
  292.    Relay framing, when those frames are detected.
  293.  
  294.    By prior configuration, octet-synchronous HDLC [2] is recommended
  295.    where the network termination equipment interfaces directly to the T
  296.    reference point, and octet boundaries are available at the time of
  297.    framing.  Such equipment is likely to be highly integrated, and the
  298.    elimination of bit-synchronous hardware can reduce the part count,
  299.    resulting in lower cost interfaces and simpler configuration.
  300.    Octet-synchronous HDLC MUST be used with NRZ bit encoding.
  301.  
  302.    For D-channels, by default no data service is expected.  By prior
  303.    configuration, "PPP in X.25" [3] or "PPP in Frame Relay" [4] framing
  304.    MAY be used.
  305.  
  306.    Despite the fact that HDLC, LAPB, LAPD, and LAPF are nominally
  307.    distinguishable, multiple methods of framing SHOULD NOT be used
  308.    concurrently on the same ISDN channel.
  309.  
  310.  
  311.  
  312.  
  313.  
  314.  
  315.  
  316.  
  317.  
  318.  
  319.  
  320.  
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333. Simpson                  expires in six months                  [Page 4]
  334. DRAFT                        PPP over ISDN                September 1993
  335.  
  336.  
  337. 4.  In-Band Format Detection
  338.  
  339.    It is possible to connect an ISDN circuit to an X.25 or Frame Relay
  340.    circuit.  This results in the receipt of a different type of frame.
  341.    These other valid formats for PPP framing MUST be detected.
  342.  
  343.    First, the frames MUST be checked for a valid FCS.  All of these
  344.    framing methods use the same FCS.  Those frames which fail the FCS
  345.    test MUST be silently discarded.
  346.  
  347.    The PPP HDLC framing is easily distinguished from X.25 or Frame Relay
  348.    frames.  Initial PPP frames always start with the sequence ff-03-c0-
  349.    21.
  350.  
  351.    Initial X.25 frames will have a first octet which is odd (the least
  352.    significant bit is 1), and which likely will have the value 1 or 3.
  353.    The implementation MUST check for a valid Control octet, and SHOULD
  354.    check for a supported encapsulation.  If a valid X.25 frame is
  355.    detected, and X.25 is supported and enabled, the implementation MUST
  356.    change to the "PPP in X.25" [3] framing method.
  357.  
  358.    Initial Frame Relay frames have a first octet which is even (the
  359.    least significant bit is 0).  The implementation MUST check for a
  360.    valid Control octet, and SHOULD check for a supported encapsulation.
  361.    If a valid Frame Relay frame is detected, and Frame Relay is
  362.    supported and enabled, the implementation MUST change to the "PPP in
  363.    Frame Relay" [4] framing method.
  364.  
  365.    An implementation that does not support X.25 or Frame Relay framing
  366.    MAY continue to send PPP HDLC framing after recognizing possible X.25
  367.    or Frame Relay frames.  When the Restart Counter reaches 0, the
  368.    current configuration attempt is abandoned as usual.
  369.  
  370.    The accidental connection of a PPP circuit to feed a multipoint
  371.    network (or multicast group) MUST result in link configuration
  372.    failure.  An implementation that supports X.25 or Frame Relay framing
  373.    can detect multiple responses to the LCP Configure-Request, with the
  374.    same Identifier, coming from what appear to be multiple LAPB or LAPD
  375.    addresses.
  376.  
  377.    Implementations SHOULD follow good error recovery practice, including
  378.    logging or reporting information about the causes of link
  379.    configuration failure.  Examples of such information include the type
  380.    and initial octets of X.25 or Frame Relay frames.  Some
  381.    implementations might be physically unable to either log or report
  382.    such information.
  383.  
  384.  
  385.  
  386.  
  387.  
  388. Simpson                  expires in six months                  [Page 5]
  389. DRAFT                        PPP over ISDN                September 1993
  390.  
  391.  
  392. 5.  Out-of-Band signaling
  393.  
  394.    Experience has shown that the LLC Information Element is not reliably
  395.    transmitted end to end.  The deployment of compatible switches is too
  396.    limited, and the subscription policies of the providers are too
  397.    diverse.  Therefore, transmission of the LLC-IE SHOULD NOT be relied
  398.    upon for framing or encoding determination.
  399.  
  400.    No LLC-IE values which pertain to PPP have been assigned.  Any other
  401.    values which are received are not valid for PPP links, and can be
  402.    ignored for PPP service.
  403.  
  404.    As an alternative administrative measure, multiple directory numbers
  405.    can point to the same physical access facility, by binding particular
  406.    services to each directory number.  The called party identifier has
  407.    proven to be reliably provided by the local switch.
  408.  
  409.    When a called party identifier is used, or when a future LLC-IE value
  410.    is assigned to PPP and the PPP value is received, if the LCP has not
  411.    had the administrative Open event, the call MUST be rejected.
  412.    Receivers MUST NOT accept an incoming call, only to close the circuit
  413.    or ignore packets from the circuit.
  414.  
  415.  
  416. 6.  Configuration Details
  417.  
  418.    The LCP recommended sync configuration options apply to ISDN links.
  419.  
  420.    The standard LCP sync configuration defaults apply to ISDN links.
  421.  
  422.    The typical network feeding the link is likely to have a MRU of
  423.    either 1500, or 2048 or greater.  To avoid fragmentation, the
  424.    Maximum-Transmission-Unit (MTU) at the network layer SHOULD NOT
  425.    exceed 1500, unless a peer MRU of 2048 or greater is specifically
  426.    negotiated.
  427.  
  428.    Instead of a constant value for the Restart timer, the exponential
  429.    backoff method is recommended.  The Restart Timer SHOULD be 250
  430.    milliseconds for the initial value, and 3 seconds for the final
  431.    value.
  432.  
  433.    Implementations that include persistent dialing features, such as
  434.    "demand dialing" or "redialing", SHOULD use mechanisms to limit their
  435.    persistence.  Examples of such mechanisms include exponential
  436.    backoff, and discarding packet queues after failure to complete link
  437.    establishment.  In some implementations, discarding the transmit
  438.    queue can temporarily remove the stimulus to retry the connection.
  439.  
  440.  
  441.  
  442.  
  443. Simpson                  expires in six months                  [Page 6]
  444. DRAFT                        PPP over ISDN                September 1993
  445.  
  446.  
  447. Security Considerations
  448.  
  449.    Security issues are not discussed in this memo.
  450.  
  451.  
  452. References
  453.  
  454.    [1]   Simpson, W. A., "The Point-to-Point Protocol (PPP)", work in
  455.          progress.
  456.  
  457.    [2]   Simpson, W.A., "PPP in HDLC Framing", work in progress.
  458.  
  459.    [3]   Simpson, W.A., "PPP in X.25", work in progress.
  460.  
  461.    [4]   Simpson, W.A., "PPP in Frame Relay", work in progress.
  462.  
  463.    [5]   Sklower, K., "PPP MultiLink Procedure", work in progress.
  464.  
  465.    [6]   CCITT, "Recommendation V.120: Data Communications over the
  466.          Telephone Network", Blue Book, ITU 1988
  467.  
  468.    [7]   Stallings, W, "ISDN and Broadband ISDN - 2nd ed", Macmillan,
  469.          1992.
  470.  
  471.  
  472. Acknowledgments
  473.  
  474.    This design was inspired by the paper "Parameter Negotiation for the
  475.    Multiprotocol Interconnect", Keith Sklower and Clifford Frost,
  476.    University of California, Berkeley, 1992, unpublished.
  477.  
  478.    Other details were gleaned from "Determination of Encapsulation of
  479.    Multi-protocol Datagrams in Circuit-switched Environments", Keith
  480.    Sklower, University of California, Berkeley, IETF IPLPDN WG draft,
  481.    July 1993.  That paper credits previous work "A Subnetwork Control
  482.    Protocol for ISDN Circuit-Switching", Leifer, D., Sheldon, S. and
  483.    Gorsline, B.; IETF IPLPDN WG draft, March 1991; and "A Negotiation
  484.    Protocol for Multiple Link-Protocol over ISDN Circuit-Switching",
  485.    Muramaki, K. and Sugawara, T.; IETF IPLPDN WG draft, May 1992.
  486.  
  487.    Thanks to Oliver Korfmacher (NetCS) for European considerations, Dory
  488.    Leifer (University of Michigan) for technical details and called
  489.    party signalling, and Vernon Schryver (Silicon Graphics) regarding
  490.    handling of link misconfiguration.
  491.  
  492.    Special thanks to Morning Star Technologies for providing computing
  493.    resources and network access support for writing this specification.
  494.  
  495.  
  496.  
  497.  
  498. Simpson                  expires in six months                  [Page 7]
  499. DRAFT                        PPP over ISDN                September 1993
  500.  
  501.  
  502. Chair's Address
  503.  
  504.    The working group can be contacted via the current chair:
  505.  
  506.       Fred Baker
  507.       Advanced Computer Communications
  508.       315 Bollay Drive
  509.       Santa Barbara, California, 93111
  510.  
  511.       EMail: fbaker@acc.com
  512.  
  513.  
  514. Author's Address
  515.  
  516.    Questions about this memo can also be directed to:
  517.  
  518.       William Allen Simpson
  519.       Daydreamer
  520.       Computer Systems Consulting Services
  521.       1384 Fontaine
  522.       Madison Heights, Michigan  48071
  523.  
  524.       EMail: Bill.Simpson@um.cc.umich.edu
  525.  
  526.  
  527.  
  528.  
  529.  
  530.  
  531.  
  532.  
  533.  
  534.  
  535.  
  536.  
  537.  
  538.  
  539.  
  540.  
  541.  
  542.  
  543.  
  544.  
  545.  
  546.  
  547.  
  548.  
  549.  
  550.  
  551.  
  552.  
  553. Simpson                  expires in six months                  [Page 8]
  554. DRAFT                        PPP over ISDN                September 1993
  555.  
  556.  
  557.                            Table of Contents
  558.  
  559.  
  560.      1.     Introduction ..........................................    1
  561.  
  562.      2.     Physical Layer Requirements ...........................    2
  563.  
  564.      3.     Framing ...............................................    4
  565.  
  566.      4.     In-Band Format Detection ..............................    5
  567.  
  568.      5.     Out-of-Band signaling .................................    6
  569.  
  570.      6.     Configuration Details .................................    6
  571.  
  572.      SECURITY CONSIDERATIONS ......................................    7
  573.  
  574.      REFERENCES ...................................................    7
  575.  
  576.      ACKNOWLEDGEMENTS .............................................    7
  577.  
  578.      CHAIR'S ADDRESS ..............................................    8
  579.  
  580.      AUTHOR'S ADDRESS .............................................    8
  581.  
  582.  
  583.  
  584.  
  585.  
  586.  
  587.  
  588.  
  589.  
  590.  
  591.  
  592.  
  593.  
  594.  
  595.  
  596.  
  597.  
  598.  
  599.  
  600.  
  601.  
  602.  
  603.  
  604.  
  605.  
  606.  
  607.  
  608.